NFS Illustrated by Brent Callaghan

Author:Brent Callaghan [Callaghan, Brent]
Language: eng
Format: epub, pdf
Publisher: Pearson Education
Published: 1999-12-23T16:00:00+00:00

Chapter 10. NFS Lock Manager Protocol

The team that designed the NFS protocol consciously omitted file locking operations. Although simple file operations like READ and WRITE could be generalized across different operating systems, there was no clear consensus on what should constitute a general file and record locking protocol. In 1984, Bill Joy, one of the architects of the NFS protocol, replied to a question on the omission of file locking:

When we started the company [Sun Microsystems, Inc.] I went around and talked to the people I respect the most who were doing databases, and asked them well, if I gave you this and I gave you that . . . first of all, what would you want and if I gave you this or that would you use it . . . and it was very discouraging because they just basically said just make the file system fast and we’ll do the rest ourselves, and they almost didn’t want anything that I thought of giving them.1

In addition, locking by its very nature implies a stateful server with additional complexity in recovering lock state following a server crash and reboot. As it turned out, there was a customer demand for file locking to be supported for not only the whole file locks of Berkeley UNIX clients but also the byte-range locking required by UNIX System V, Release 4 clients. File locking was added to SunOS clients and servers in the SunOS 3.2 release in 1986.

The Network Lock Manager protocol depends on another RPC protocol, the Network Status Monitor protocol, to notify clients and/or servers of loss of lock state resulting from a crash/reboot. The Status Monitor protocol is also described in this chapter.

The interaction of these protocols, the use of asynchronous RPC calls and callbacks, and the multiplicity of locking procedures (monitored vs. nonmonitored, record vs. share reservations, and so on) make this a difficult protocol to implement successfully. For this reason, some NFS server implementations have neglected to support the Lock Manager protocol. NFS clients that encounter these servers must resort to local locking.

The Lock Manager protocol assumes a locking model that allows a client application to lock a region of a file defined by an offset and a length. A lock can span an entire file, starting with an offset of zero and with a length that extends to the last byte (Figure 10.1). A locked region can also extend beyond the last byte of a file. The extension of a range beyond the end-of-file is to allow additional data to be appended to the file within the protection of a lock. A locked region can be controlled by one of two different types of lock. A shared lock allows other applications to read the data in the region but not modify it. Multiple clients can hold shared locks on the same region of a file, or overlapping regions. An exclusive lock prevents other applications from reading or writing data in the region. Another client cannot establish any lock on a region that is covered by an exclusive lock.

Download

Copyright Disclaimer:
This site does not store any files on its server. We only index and link to content provided by other sites. Please contact the content providers to delete copyright contents if any and email us, we'll remove relevant links or contents immediately.